A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
1. Field of the Invention
The present invention relates generally to information processing environments and, more particularly, to computer-implemented methodology related to two-phase commit decisions in transaction processing systems.
2. Description of the Background Art
Today, most computers are linked to other computer systems via a computer network. Well-known examples of computer networks include local-area networks (LANs) where the computers are geographically close together (e.g., in the same building), and wide-area networks (WANs) where the computers are farther apart and are connected by telephone lines or radio waves.
Often, networks are configured as xe2x80x9cclient/serverxe2x80x9d networks, such that each computer on the network is either a xe2x80x9cclientxe2x80x9d or a xe2x80x9cserver.xe2x80x9d Servers are powerful computers or processes dedicated to managing shared resources, such as storage (i.e., disk drives), printers, modems, or the like. Servers are often dedicated, meaning that they perform no other tasks besides their server tasks. For instance, a database server is a computer system that manages database information, including processing database queries from various clients. The client part of this client-server architecture typically comprises PCs or workstations which rely on a server to perform some operations. Typically, a client runs a xe2x80x9cclient applicationxe2x80x9d that relies on a server to perform some operations, such as returning particular database information. Often, client-server architecture is thought of as a xe2x80x9ctwo-tier architecture,xe2x80x9d one in which the user interface runs on the client or xe2x80x9cfront endxe2x80x9d and the database is stored on the server or xe2x80x9cback end.xe2x80x9d The actual business rules or application logic driving operation of the application can run on either the client or the server (or even be partitioned between the two). In a typical deployment of such a system, a client application, such as one created by an information service (IS) shop, resides on all of the client or end-user machines. Such client applications interact with a host database system (e.g., Borland Interbase(copyright)), which execute business logic (e.g. within database stored procedures) that traditionally ran at the client machines.
Database systems are well documented in the technical, trade and patent literature. See e.g., Date, C. xe2x80x9cAn Introduction to Database Systems, Volume I and II,xe2x80x9d Addison Wesley, 1990, the disclosure of which is hereby incorporated by reference. A more technical review is provided by Gray, J. and Reuter, A., xe2x80x9cTransaction Processing: Concepts and Techniques,xe2x80x9d Morgan Kaufmann Publishers, 1993, the disclosure of which is hereby incorporated by reference.
More recently, the development model has shifted from standard client/server or two-tier development to a three-tier, component-based development model. This newer client/server architecture introduces three well-defined and separate processes, each typically running on a different platform. A xe2x80x9cfirst tierxe2x80x9d provides the user interface, which runs on the user""s computer (i.e., the client). Next, a xe2x80x9csecond tierxe2x80x9d provides the functional modules that actually process data. This middle tier typically runs on a server, often called an xe2x80x9capplication server.xe2x80x9d A xe2x80x9cthird tierxe2x80x9d furnishes a database management system (DBMS) that stores the data required by the middle tier. This tier may run on a second server called the database server.
Three-tier database systems are well documented in the patent and trade literature; see, e.g., U.S. Pat. No. 6,266,666, entitled xe2x80x9cComponent transaction server for developing and deploying transaction-intensive business applicationsxe2x80x9d, the disclosure of which is hereby incorporated by reference.
The three-tier design has many advantages over traditional two-tier or single-tier designs. For example, the added modularity makes it easier to modify or replace one tier without affecting the other tiers. Separating the application functions from the database functions makes it easier to implement load balancing. Thus, by partitioning applications cleanly into presentation, application logic, and data sections, the result will be enhanced scalability, reusability, security, and manageability.
In the three-tier model, communication must occur among the various tiers, such as from a client to a middle tier, and from the middle tier to one or more back-end databases. One of the advantages of employing a middle tier is to pool together connections to the database in a central (middleware) tier, thus allowing more efficient access to the database. In particular, database connections, which are expensive in terms of system and network resources, are cached in the middle tier.
Another advantage of the middle tier is to offload certain computations from the back-end databases, particularly those pertaining to business logic (i.e., business objects). Exploiting this advantage, a system administrator would deploy a middle tier on a separate server computer, one that was physically separate from the computers hosting the back-end databases.
In many cases, a particular application may access and modify data that is stored in several different databases, including ones provided by different vendors. For example, a banking application may access customer checking account information stored in one database as well as savings account information stored in a second database. In commercial transaction processing systems there is frequently a need to coordinate the process of making changes to multiple databases because a single transaction can update many different databases. For example, in a consumer banking application, an account holder may wish to transfer $500 from his or her savings account to his or her checking account. This transaction actually involves a pair of operations. The first operation is to remove (or debit) $500 from the savings account. The second operation is to add (or credit) $500 to the checking account. Both the bank and the account holder want to ensure that if the bank""s computer system crashed in the middle of this transfer, there is a way to make sure that either the $500 is posted to the checking account, or, alternatively, that the $500 is not removed from the savings account. It is unacceptable if the funds are removed from savings, but are not credited to checking. In other words, this transaction requires a mechanism to guarantee xe2x80x9catomicity.xe2x80x9d Atomicity means that all actions that take place as part of a transaction are executed as a single atomic operation and that either they all complete, or none of them complete.
In transactions involving a single database, atomicity typically involves the following operations which are all handled as part of the standard operations of the database management system:
1. Begin: Beginning a transaction creates a transaction scope. From the time the transaction is begun until it is successfully committed or rolled back, operations against the database will be within the scope of the transaction and will either all succeed or all fail.
2. Commit: Committing a transaction tells the database that all processing has completed satisfactorily, and that the results should be written to persistent storage. Before a commit is issued, changes may be undone by issuing a xe2x80x9crollbackxe2x80x9d command. If there is a system crash prior to a commit, on recovery the database will revert to the state it was in before the transaction was begun. Executing the commit ends the transaction.
3. Rollback: Rolling back a transaction revokes any changes that occurred during the transaction, leaving the database in the state in which it was found prior to the transaction. After a transaction is committed, it can no longer be rolled back.
Two-phase commit (or xe2x80x9c2PCxe2x80x9d) is a well-known technique to synchronize multiple resources and to provide the guarantee of atomicity that is required in transaction processing systems. The two-phase commit protocol has two phases that are typically referred to as xe2x80x9cPreparexe2x80x9d and xe2x80x9cCommit.xe2x80x9d In the Prepare stage, all resource managers (databases most typically) participating in the transaction are told by a transaction manager to prepare to commit their changes. The databases are instructed to perform all processing steps short of writing the updates to persistent storage. After each database completes the xe2x80x9cPreparexe2x80x9d phase, it sends a reply to the transaction manager indicating success (vote commit) or failure (vote rollback). After a database votes commit (indicating success), it may not initiate a rollback and may only implement a rollback if instructed to do so by the transaction manager.
The transaction manager collects the replies from all the involved databases. A single vote rollback results in the rollback of the entire transaction. If the transaction manager receives no response from one of the participants, it assumes the operation has failed and rolls back the transaction. The transaction manager rolls back the transaction by sending a rollback instruction to all participating databases.
If the Prepare stage has completed satisfactorily (i.e., if all databases voted commit), the transaction manager enters the Commit phase. In this phase, the transaction manager instructs each of the participating databases to commit their changes. After completion, each database reports to the transaction manager that it has completed the transaction. When all databases report completion, the transaction is completed. The two-phase commit protocol is described in more detail in the Open Group Technical standard titled xe2x80x9cDistributed TP: The XA Specification,xe2x80x9d C193, ISBN 1-872630-24-3, February, 1992, and in the Open Group Guide titled xe2x80x9cDistributed TP: Reference Model, Version 3,xe2x80x9d G504, ISBN 1-85912-170-5, February 1996, the description of which are hereby incorporated by reference.
Unfortunately, participating in two-phase commit is relatively expensive, in terms of overhead on transaction performance, as a result of having to involve a transaction manager to coordinate the above-described process of making changes across multiple systems. This two-phase commit process involves several additional steps that are not required for transactions involving only database reads or changes to only one database. As a result, performance is slowed in transactions in which the two-phase commit protocol is used.
Very frequently, however, a given transaction involving an application accessing data in more than one database does not actually make any changes (i.e., it is a read-only transaction). In many other situations, a given transaction involves changes being made to only one of the participating databases. In such cases, it would be advantageous to avoid the setup overhead of two-phase commit for transactions that do not involve changes to more than one database.
Unfortunately, however, it is usually difficult to determine in advance whether a given transaction will require changes to multiple systems, due to the fact that most transactions have data driven behavior (meaning that the behavior is based on data inputs and it is therefore difficult to predetermine the behavior). Therefore, existing transaction processing systems typically make the pessimistic assumption that all transactions require two-phase commit, thereby always incurring the performance overhead of setting up two-phase commit even though it is not required for many transactions.
One approach to handle this problem is to configure a system such that two databases can never participate in a single transaction. This configuration avoids the two-phase commit overhead, but introduces an application-level limitation that is frequently unacceptable to a customer trying to deploy a particular database solution.
Existing transaction processing systems typically always incur the overhead of setting up two-phase commit even though only a small percentage of transactions actually result in changes being made to more than one database. To improve the performance of transaction processing systems, there is a need for an improved system and methodology for use of the two-phase commit protocol.
Glossary
The following definitions are offered for purposes of illustration, not limitation, in order to assist with understanding the discussion that follows.
Application server: Also called an xe2x80x9cappserver,xe2x80x9d this is a middleware program/process that handles all application operations between users and an organization""s back-end business applications or databases. Application servers are typically used for complex transaction-based applications. To support high-end needs, an application server must have built-in redundancy, monitors for high-availability, high-performance distributed application services, and support for complex database access.
Commit: This is a database command to make changes to data permanent. In the context of a database transaction, a transaction xe2x80x9ccommitsxe2x80x9d when all pending changes (if any) to a target database(s) are made permanent.
Java: A general purpose programming language developed by Sun Microsystems. Java is an object-oriented language similar to C++, but simplified to eliminate language features that cause common programming errors. Java source code files (files with a .java extension) are compiled into a format called bytecode (files with a class extension), which can then be executed by a Java interpreter. Compiled Java code can run on most computers because Java interpreters and runtime environments, known as Java Virtual Machines (JVMs), exist for most operating systems, including UNIX, the Macintosh OS, and Windows. Bytecode can also be converted directly into machine language instructions by a just-in-time compiler (JIT). Further description of the Java Language environment can be found in the technical, trade, and patent literature; see e.g., Gosling, J. et al., The Java Language Environment: A White Paper, Sun Microsystems Computer Company, October 1995, the disclosure of which is hereby incorporated by reference.
Rollback: This is a database command to undo all work since the transaction was begun.
SQL: Structured Query Language is a well-known language for processing database information.
Transaction: A unit of work performed against one or more databases. A transaction may be successfully concluded by a xe2x80x9ccommitxe2x80x9d operation, whereupon all pending changes (if any) are written to the database(s).
Transactional control: The ability to manage various transactions that may occur within a relational database management system.
Two-phase commit protocol: The two-phase commit protocol is the most widely used atomic commitment protocol and is supported by all modem commercial database systems and transaction processing monitors. The two-phase commit protocol was developed by the Open Group (formerly the X/Open Company Limited) and has been standardized by the International Standards Organization (ISO92).
XA: The Open Group XA specification defines a set of application programming interfaces (APIs) or commands that work with the underlying standard two-phase commit protocol. In order to participate in an XA-defined two phase commit, transaction managers and resource managers must map their private two-phase commit protocols to the XA commands. In this document references to xe2x80x9cXAxe2x80x9d shall refer generally to this set of application program interfaces.
In general, most real world transactions on transaction processing systems do not access multiple data sources. Rather, in a majority of transactions only one data source is accessed. In addition, transactions typically read from databases much more frequently than they write to databases. Thus, an even smaller percentage of transactions result in updates (changes) being written to more than one database.
Although the transactions resulting in updates to multiple databases are very rare, existing transaction processing systems typically require use of the two-phase commit protocol (xe2x80x9c2PCxe2x80x9d) for every transaction. This results in a considerable performance penalty on the operations of the system.
The present invention provides a transaction processing system incorporating improved methodology for invoking 2PC only when it is needed. Using this improved methodology, the transaction is handled without use of 2PC until it is determined that the transaction does, in fact, involve updates to more than one database. The present invention introduces a decision between the xe2x80x9creadxe2x80x9d and xe2x80x9cwritexe2x80x9d halves of the transaction. The decision determines how many systems (if any) need to be changed (or written) during the xe2x80x9cwritexe2x80x9d half of the transaction. If less than two systems require modification (i.e., if no changes are made or if changes are only made to one database), then the xe2x80x9cwritexe2x80x9d half of the transaction can proceed without using 2PC. In this way 2PC is only used when two or more systems are modified and the overhead associated with two-phase commit is avoided when it is not necessary.
An improved method providing or supporting two-phase commit protocol (2PC), particularly in the context of accessing multiple databases, may be summarized as follows. In response to a transaction initiated by a client (e.g., via SQL query commands), a transaction processing system of the present invention initiates connections to databases participating in the transaction without use of 2PC. In other words, the system optimistically presumes at the outset that 2PC will not be required. Next, the system reads in records required in the transaction from the databases. Subsequently, the system determines whether the transaction in fact results in changes to more than one database. How the system operates from this point on depends on this determination. In the instance that the transaction results in changes to no more than one database, the system may complete the transaction without use of 2PC. On other hand, if the transaction results in changes to more than one database, the system uses 2PC to complete the transaction.
All told, the improved method of the present invention improves overall performance by looking at each transaction to determine whether the transaction actually requires use of 2PC before incurring the overhead associated with use of 2PC. Because only a small percentage of transactions result in updates to more than one database, the approach of the present invention increases overall system performance considerably by avoiding 2PC overhead in the many instances where it is unnecessary.